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1 . Summary 


The  purpose  of  this  project  is  to  provide  seismic  data 
storage  and  retrieval  services.  These  services  are  to  be 
provided  via  the  Datacomputer  being  developed  and  maintained 
by  Computer  Corporation  of  America  (CCA)  for  ARPA  under  a 
separate  Contract  No.  MDA903-74-C-0225 . The  seismic  data  is  to  be 
received  over  the  Arpanet  and  made  available  to  a variety  of 
computers  on  the  Arpanet. 

[V 

To  provide  the  requisite  services  the  Datacomputer  must  be  augmented 
by  a mass  memeory  system  to  provide  additional  storage  and  by  a 
small  Seismic  Input  Processor  (SIP)  to  continuously  collect  data 
over  the  network,  reformat  ard  buffer  it,  and  periodically  burst 
it  into  the  Datacomputer.  An  Ampex  Terabit  Memory  System  (TBM) 
with  a capacity  of  two  hundred  billion  bits  has  been  ordered  for 
the  mass  memory  system  and  will  be  installed  at  CCA  in  early  1976. 

A DEC  11/40  computer  with  RP04  disks  and  an  Arpanet  interface  has 
bee  installed  as  the  hardware  for  the  SIP.  Development  of  the 
SIP  software  is  nearly  complete. 

Project  activity  can  be  divided  into  four  catagories:  (1)  SIP 

development  and  network  bandwidth  considerations;  (2)  coordination 
with  the  seismic  community;  (3)  TBM  acquisition  and  integration 
int  the  Datacomputer;  and  (4)  seismic  related  Datacomputer 
development.  One  section  below  in  this  report  is  devoted  to 
each  of  these  categories. 

2 . SIP  and  Arpanet 

Seismic  array  data  is  collected  from  the  SDAC  Communications  and 
Control  Processor  (CCP)  over  the  Arpanet,  buffered,  and  refor- 
matted, all  by  the  CCA  Seismic  Input  Processor  (SIP)  which 
retransmits  the  data  to  the  Datacomputer.  The  SIP  is  equipped 
with  disk  storage  adequate  for  24-hour  buffering  of  a 15  kilobit 
per  second  data  stream.  See  Figure  1 . 
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2 . 1 Operations 


A version  of  the  SIP  became  operational  in  this  quarter. 

More  than  one  hundred  hours  of  real  seismic  array  data 
were  received  form  the  CCP,  reorganized,  formatted, 
buffered  on  the  SIP’s  disk,  and  forwarded  to  the 
Datacomputer . Minor  improvements  are  still  being  made  in 
the  SIP. 

2 . 2 Arpanet 

For  the  proper  Datacomputer  support  of  seismic  data, 
fairly  high  Arpanet  bandwidths  are  required.  The  Arpanet 
should  in  principle  be  able  to  provide  thse  bandwidths; 
however,  considerable  difficulties  were  encountered  during 
this  quarter. 

Some  of  the  dif f iculities  appear  to  have  been  encountered 
due  to  the  Pluribus  IMP  at  SDAC . There  seem  to  have  been 
both  software  and  hardware  problems  with  the  Pluribus, 
but  there  was  indication,  toward  the  end  of  this  quarter, 
that  these  problems  were  on  their  way  to  being  solved. 

More  intractible  problems  have  been  encountered  due  to 
limited  reassembly  buffers  at  the  CCA  Arpanet  IMP.  Achieving 
high  bandwidth  over  the  Arpanet  required  that  large  messages 
be  sent  which  the  network  breaks  into  packets  and  reassembles 
at  the  destination.  To  avoid  internal  lockups  in  the  net- 
work, large  messages  are  not  fully  accepted  until  space  for 
reassembly  has  been  reserved  at  the  destination.  This 
scheme  places  demands  on  reassembly  buffers  proportional  to 
the  bandwidth  of  a datastream  (number  of  messag.es  per 
second)  and  the  delay  between  source  and  destination  (usually 
proportional  to  the  number  of  intervening  network  nodes). 

The  CCA  IMP  has  enough  buffer  space  for  only  three  large 
messages.  The  two  large  messages  a second  from  the  CCP 
to  the  SIP  and  the  traffic  from  the  SIP  to  the  Datacomputer 
saturate  the  CCA  IMP  so  that  any  significant  amount  of  other 


traffic  causes  gross  congestion  and  such  difficulties 
as  a high  level  of  incomplete  transmissions  (messages 
accepted  but  not  delivered)  due  to  insufficient  resources. 

This  difficulty  is  likely  to  become  increasingly  severe  due 
to  seismic  data  retrievals,  direct  storage  of  non-arra,  data 
from  Albuquerque  Seismological  Center  (ASC)  into  the 
Datacomputer,  increased  flow  of  array  seismic  data  from  the 
CCP  through  the  SIP  into  the  Datacomputer,  and  other 
increased  use  cf  the  CCA  IMP. 

Short  term  solutions  that  have  been  suggested  by  CCA  for 
sometime  include  removal  of  the  Lincoln  Laboratories  V 
interface  from  CCA  IMP  and/or  installation  of  more  direc 
internal  network  communication  lines.  However,  the  extent 
of  relief  offered  by  such  short  term  solutions  is  limlte  , 
and  the  only  long  term  solution  appears  to  be  to  mstal  a 
higher  capacity  IMP  at  CCA,  presumably  a Plunbus  IM  . 

It  should  be  pointed  out  that  these  problems  are  not  within 
CCA’s  purview.  We  must  rely  on  those  who  have  responsibility 
for  proper  Arpanet  operation  to  provide  adequate  service. 


2 . 3 CCP-SIP  Protocol 

At  this  point  enough  experience  has  been  accumulated  with 
the  CCP-SIP  transmission  protocol  to  point  out  two  ways 
which  it  was  inadequately  specified  in  a way  that  turned 
out  to  be  disadvantageous  to  the  SIP. 

First,  the  effect  of  the  SIP-to-CCP  message  (provided  for 
in  the  protocol)  saying  that  the  SIP  was  going  down  is  not 
to  stop  an,  CCP  messages  to  the  SIP.  The  CCP  appears  to  stop 
transmitting  only  if  the  SIP  brings  down  its  host  ready  1 ne. 
To  avoid  disruption  to  the  CCP,  the  SIP  has  to  assure  that 
the  CCP  stops  sending  messages  about  the  time  the  SI?  has 
slot  pod  listening,  and  thus  th,  SIP  has  to  bring  down 


its  host  ready  line  even  for  brief  debugging  halts.  This 
turns  out  to  be  inconvenient,  as  it  destroys  information 
and  disrupts  communication  between  the  SIP  and  the 
Datacomputer . 

Second,  no  information  is  given  in  the  protocol  on  how  the 
unique  message  ID  numbers  are  to  be  computed.  This  has  no 
effect  on  their  utility  in  acknowledgements,  which  is  the 
primary  concern  of  the  protocol.  However,  these  numbers,  if 
they  had,  for  example,  been  specified  to  be  sequential  in  one 
or  more  series,  might  have  been  useful  for  duplicate  and 
out-of-order  message  detection,  especially  for  the  asynchronous 
status  messages. 

Also,  in  order  to  alleviate  some  of  the  network  congestion 
problems  mentioned  in  2.2  above,  the  number  of  retransmissions 
for  messages  was  decreased  to  one.  Messages  are  retrans- 
mitted if  not  rapidly  acknowledged  and, since  network  congestion 
may  cause  delayed  acknowledgements,  excessive  retransmissions 
can  make  the  congestion  worse. 

2 . The  Software 

The  SIP's  software  can  be  divided  into  three  sections: 

(l)the  basic  SIP  operating  system,  which  is  complete  and  has 
stabilized,  (2)  the  tasks  that  manage  communications  with 
the  CCP  by  a special  protocol  and  store  the  information 
received  from  it  on  the  STP's  disk,  and  (3)  the  NCP  and  other 
tasks  that  manage  communications  with  the  Datacomputer  and  send 
it  information  retrieved  from  the  SIP's  disk. 

It  has  been  demonstrated  that,  in  practice,  a very  simple 
algorithm  can  oe  used  in  storing  formatted  array  seismic  data 
on  the  SIP's  disk.  Such  data  is  synchronous  with  one  message 
a second  and  normally  arrives  in  chronological  order. 

There  can  be,  however,  gaps,  duplicate  messages,  messages 
arriving  out  of  order  due  to  retransmissions,  etc.  The  SIP 
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is  net  immediately  concerned  with  such  irregularities 
as  it  simply  stores  data  for  each  site  and  type  into 
hourly  files  by  doing  an  update  in  place,  reading  in  the 
relevant  part  of  the  file  from  disk,  modifying  it,  and 
writing  it  back  out,  before  going  on  to  the  next  message. 

More  complex  techniques  to  accumulate  updates  in  core 
and  reduce  disk  operations  have  proven  unnecessary. 

The  SIP  periodically  sends  data  in  chunks  of  up  to  one 
hour  over  to  the  Datacomputer , also  using  an  update-in- 
place philosophy  for  the  seismic  array  information. 

Since  there  are  fixed  slots  for  each  site,  type,  and 

second  of  information,  no  problems  are  caused  by  accidentiall; 

resending  data  or  sending  hours  in  nonchronological  order. 

At  worst,  data  is  overwritten  with  identical  data. 

An  interesting  class  of  problems  encountered  in  developing 
the  SIP  were  various  sorts  of  internal  buffer  lock-ups. 

One  form  of  congestion  involved  the  SIP  filling  up  with 
output  messages  so  as  to  have  no  room  for  input  while  the 
CCA-IMP  was  refusing  to  accept  messages  until  it  could 
deliver  one  to  the  SIP.  This  problem  was  overcome  by  more 
compactly  encoding  acknowledgement-type  output  messages  and 
limiting  the  number  that  could  accumulate  before  they  were 
discarded.  The  second  lock-up  problem  involved  the  SIP 
accepting  a burst  of  input  messages  such  that  no  space  was 
left  to  process  and  thus  free  any  of  the  buffers  with  input 
messages  in  them.  This  problem  was  solved  by  modifications 
to  the  buffer  allocation  routines  so  as  not  to  allocate  input 
buffers  where  it  might  cause  such  a lock-up. 

3 . Coordination  with  the  Seismic  Community 

Towards  the  end  of  this  quarter,  real  seismic  data  was  available 
from  small  test  files  in  both  the  regular  Datacomputer  and  a new 
experimental  Datacomputer.  VSC  and  SDAC  were  informed  of  the 
availability  of  this  data  and  assisted  in  its  retrieval. 
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CCA  also  cooperated  with  SDAC  in  developing  files  that  will  be 
written  directly  by  SDAC.  These  are  anticipated  to  be  the 
event  summary  files,  seismic  waveform  files,  and  the  instrument 
status  and  calibration  file. 

4.  The  TBM 

An  Ampex  Terabit  Memory  System (TBM)  will  be  part  of  the  Datacomputer 
to  provide  the  required  large  amount  of  on-line  storage.  The  TBM 
has  required  site  modifications  at  CCA. 

4 . 1 Site  Preparation 

In  early  February  the  vacuum  and  air  compressor  systems  for  the 
TBM  arrived  and  were  installed.  All  of  the  TBM  equipment 
except  for  the  second  dual  transport  drive  arrived  February  23. 

Some  minor  cosmetic  touch-ups  were  also  done  during  this  quarter. 
The  only  remaining  site  work  is  the  installation  of  a new 
electric  circuit  breaker  for  some  of  the  TBM  equipment. 

Earlier  site  work  had  involved  installation  of  a new  TRANE 
air  conditioner  including  a humidifier  system  with  a replacable 
throw-away  canister.  Difficulties  have  been  encountered  with 
this  humidifier  and  with  obtaining  a spare  canister  of  the 
appropriate  type.  These  problems  may  be  related  to  the  very 
high  level  of  impurities  in  the  water  at  the  computer  site 
in  Cambridge,  Massachusetts. 

4 . 2 The  Hardware 

Progress  is  being  made  by  Ampex  toward  turning  over  the  TBM 
to  CCA  for  formal  acceptance  testing.  Some  da4  a has  been 
successfully  transferred  to  and  from  each  of  the  four  TBM 
tape  drives. 

Negotiations  between  CCA  and  Ampex  toward  agreement  on  the 
specifics  of  the  acceptance  test  has  lead  to  the  development 
of  a tree  structure,  shown  in  figure  2,  for  classification 
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Firure  2 — TBM  Error  Analysis 


UNRECOVERABLE 


of  data  errors.  This  scheme  might  be  useful  as  an  example 
in  developing  error  classifications  or  acceptance  procedures 
for  other  devices. 

5 . The  Datacomputer 

A new  experimental  version  of  the  Datacomputer  software  was  put  up 
this  quarter  in  parallel  with  the  regular  Version  1 Datacomputer 
software.  This  new  experimental  version  has  most  of  the  features 
that  Version  2 will  have  (except  that  it  does  not  yet  use  the  TBM. ) 

The  main  problem  that  had  been  encountered  in  SIP  use  of  Version  1 
was  an  inadequate  data  rate  when  storing  the  Datacomputer.  This 
was  traced  to  bugs  in  the  Version  1 routines  that  check  if  data 
conversion  is  necessary  due  to  differences,  between  source  and 
destination,  in  the  described  format  of  data.  In  this  case,  the 
source  is  the  SIP  over  the  Arpanet  and  the  destination  is  a 
seismic  array  data  file.  The  effect  of  these  bugs  was  that,  although 
the  SIP  carefully  prepares  its  data  so  that  no  conversion  is 
necessary  and  whole  records  can  be  stored  from  the  Arpanent  into  a 
file,  the  Version  1 Datacomputer,  erroneously  thinking  conversion 
might  be  necessary,  was  manipulating  the  subfields  of  each  record, 
thus  restricting  bandwidth.  These  bugs  have  been  fixed. 

The  new  version  of  the  Datacomputer  also  contains  a preliminary 
implementation  of  the  SDAX  routines  that  will  keep  track  of 
multiple  version  of  files,  staging  of  data  from  TBM  to  disk,  and 
multiple  simultaneous  readers  of  a file  along  with  one  writer. 

Since  the  new  Datacomputer  version  does  not  actually  use  the 
TBM,  SDAX  is  set  up,  for  testing  purposes,  to  stage  from  disk 
to  disk.  These  staging  operations  produce  additional  messages 
to  Inform  the  user  of  their  progress.  It  was  necessary  to  make 
some  very  minor  modification  to  the  SIP  to  adapt  it  to  these 
additional  messages. 
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